fix(agc): stop optional compute captures at their bounds - #6259

What

When APS5_DUMP_COMPUTE_PIPELINES reaches its 128-record or 256 MiB bound, the strict writer throws inside compute pipeline creation. The optional dispatch capture now stops once with a diagnostic at either bound or a host I/O failure, and skips subsequent capture filtering and SPIR-V copies. The strict Write API retains its bounds, deduplication, immutable records and diagnostics. Invalid pipeline input, damaged/incomplete records, unexpected entries and allocation failures still propagate.

PPSA01342 reached the generic error compute pipeline capture: capture directory reached 128 entries at 1385.2 seconds in the historical external experimental integration run ds-c0076. Its metadata, triage and fatal line were checked. This title observation is scoped to that experimental integration; current-main title execution has not been verified for this change.

Tested

Windows Server 2025 10.0.26100, O3 CPU tests using the actual production capture writer and repository homebrew fixture:

• Existing codec, immutable writes, malformed inputs and 5,500,000-word record tests pass.
• Actual 128-record boundary, deduplication at the cap, and stop on the next distinct record pass (1.30 s). Exactly 256 MiB is accepted and the next distinct record stops capture (1.19 s), with production limits unchanged. The original main writer fails both boundary scenarios.
• A real owned output-path conflict stops optional capture once; strict writes retain their diagnostic. Malformed input and damaged, missing, nonregular or foreign records remain errors; later optional calls do not touch their output directory.
• Selective broad-catch, omitted disabled validation and rethrown optional-I/O controls fail their intended assertions. Private injected open/write/close/read failures and allocation failure verify the production wrapper's error policy.
• The literal dispatch gate bypasses 1024 subsequent copy/filter attempts after a real I/O stop; removing its enabled check fails. Whole VulkanDevice.cpp passes O3 syntax checking with the matching component headers.

Current head 66556448b (rebased onto main 38d245448, patch unchanged), MinGW GCC 15.2 Release, NVIDIA GeForce RTX 3060 12 GB, driver 591.86:

• libSceAgcDriver builds. All seven agc_compute_pipeline* CTests pass with ANYPS5_REQUIRE_VULKAN=1 and ANYPS5_ENABLE_SPIRV_TOOLS=ON, including agc_compute_pipeline_capture_run: 2 pipelines are captured through the dispatch path and replayed without dispatch.
• The repository's branch-past-endpgm compute fixture is run with APS5_DUMP_COMPUTE_PIPELINES set to a directory already holding 128 entries, a directory at exactly 256 MiB, or a path below a regular file. On this head each run passes, prints one optional capture disabled line naming the bound or I/O error, and adds no records. With main's writer and dispatch gate the same three runs fail: the 128-entry and 256 MiB errors end the fixture with exit 1, and the I/O case raises an undeliverable filesystem_error (exit 67). An empty directory receives the same 2 records on both.

No title run or title-performance claim.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none; fix(agc): disable optional BMP dumps after host I/O failures #5800 addresses the separate optional BMP worker
• Unblocks: PPSA01342 Demon's Souls (PPSA01341) #1283 (optional-capture stop observed on the external experimental integration above)
• GPUs tested: NVIDIA GeForce RTX 3060 12 GB, driver 591.86 (32.0.15.9186), Vulkan 1.4.325, Windows Server 2025 10.0.26100; compute capture fixture and replay runs above, no title run
• AI-assisted: yes

Co-Authored-By: Codex noreply@openai.com